Learning & Information

Access Control Exploits and How to Combat Them

Mar 13, 2026 | 10 min read

A look at smart contract access control exploits in 2025 and our recommended mitigation tips - transaction simulations and effective monitoring

Smart contract vulnerabilities continue to result in substantial losses across the Web3 ecosystem. In 2025, we identified more than $50M stolen in exploits where the primary vector was insufficient or improperly implemented access controls. In at least 34 major incidents, attackers gained the ability to invoke functions or interact with privileged components of a contract that should have been restricted.

Access controls define the permissions that determine who can execute specific functions within a smart contract. They operate much like traditional permission systems by ensuring that only authorised parties can perform sensitive actions. For example, if the deed to your home were represented as a smart contract, you would expect to be the only person capable of transferring ownership or modifying its details. In the same way, many smart contracts include functions that perform critical operations such as minting tokens, withdrawing funds, or adjusting parameters that affect the entire system. These actions must be protected by robust access control mechanisms.

It is important to recognize that access control failures can appear as both simple and highly sophisticated issues. Some arise from straightforward oversights such as missing role checks or incomplete permission logic. Others involve subtle or deeply layered permission pathways that are difficult to identify, even during thorough audits. Because of this, access control vulnerabilities may seem simple in concept but can ultimately represent complex and sophisticated failures in practice.

AlexLabs Exploit

The $16M hack on AlexLabs in June 2025 demonstrates how complex smart contract vulnerabilities can be in practice. The AlexLabs protocol operates on the Stacks blockchain, a Bitcoin Layer 2 network that supports DeFi features. One of these features is a process called self-listing, which allows users to create new tokens and initialize liquidity pools. A self-listing request is only accepted if it passes several checks, including validation of a target contract address, a specific nonce, and a hash commitment that depends on both the nonce and the contract address.

To bypass these checks, the attacker exploited how Stacks derives and verifies contract addresses. They began by initiating the creation of a helper contract but aborted the deployment at nonce 2. Although no contract was actually deployed, the transaction was mined, which meant the system recorded nonce 2 as valid. As a result, the protocol believed that an address associated with nonce 2 should exist, even though the corresponding contract was never created.

The attacker then returned and used create2 on the self-listing-helper-v3a contract to deploy a malicious contract at the exact address associated with nonce 2. This malicious contract contained a transfer function designed to drain AlexLabs liquidity pools. The key weakness was that the verification logic only checked that a transaction with the expected nonce had been mined. It did not confirm that the deployment succeeded or that the deployed contract’s code matched the expected template. This allowed the attacker to insert their own contract into a position the protocol assumed was trustworthy.

While the mechanics of this exploit are highly technical, the underlying idea can be understood through a simple real-world analogy that captures its essence without oversimplifying the concepts.

The vulnerable verification can be seen below:

Stolen funds from this incident were tracked by zeroShadow to the Ethereum blockchain and were deposited into Tornado Cash.

This incident would’ve been avoided if the verification process confirmed that the deployment of the helper contract was successful, not just that a deployment was included in a block.

Real-World Analogy: The Reserved Apartment Trick

Imagine an apartment building where access to secure areas is granted to anyone who has legitimately reserved an apartment. The attacker begins by reserving Apartment #2, and the building’s system logs this reservation as valid. However, the attacker never moves in, so the apartment remains empty. The system does not check whether someone actually occupies the apartment; it only records that a reservation request was made.

Later, the same attacker returns and moves into the still-empty Apartment #2, bringing tools that allow them to reach restricted parts of the building. Because the system only verifies that “Apartment #2 was previously reserved,” it treats the attacker as legitimate. From that foothold, the attacker gains access to areas containing valuables and proceeds to steal them.

Typus Exploit

Insufficient access controls can also come in the form of simple bugs in code, such as missing statements or project mismanagement. One of the larger incidents where a simple bug in code led to serious losses was the Typus exploit on the SUI network leading to $3.44M loss.

The exploiter was able to simply bypass the access control of the project's oracle due to a missing assert statement in the oracle smart control. The update_v2 function can be seen below:

The function contains a check to ensure that only authorized addresses can call the function in the following code which checks v0 (sender of the transaction) and the list of authorized addresses (arg1.authority) and confirms whether the sender is authorized (contains). However, a missing assert means that the check isn’t enforced, hence providing access to a critical function.

The attacker repeatedly called update_v2 to manipulate the protocol's oracle and conduct swaps to drain the protocol. In order to mitigate against this threat, the code required an assert argument.

The stolen funds were bridged to the Ethereum network and remain in EOA 0x4502cf2BC9C8743E63cbb9bbdE0011989eeD03C1 until February 2026.

Real-World Analogy: The Broken ID Check

Imagine a secure facility where entry is controlled by a security guard who is supposed to check IDs before letting anyone in. The guard has a list of authorized personnel, and the process requires verifying each person against the list.

Now imagine that the guard performs the ID check but never actually stops anyone. They look at the ID, compare it to the list, and then simply wave the person through no matter what the result is. The checking step is present, but the enforcement step is missing.

A thief quickly realizes this. They walk up to the checkpoint with no authorization at all, present an ID that does not match the list, and are still allowed in because the guard does nothing when the check fails. Once inside, the thief is able to access sensitive rooms and steal valuable items.

It is clear that access control vulnerabilities are not always caught from the smart contract audit. But simple fixes like simulating transactions and real time monitoring of contracts can quickly contain a potential situation and mitigate the losses.

Solution 1: Transaction Simulation

Transaction simulation reduces the risk of blockchain immutability by showing how a transaction will execute before it is signed and broadcast, including expected state changes, permissions, and value movements. Teams can build this capability in house or bring in specialist support, and zeroShadow helps with both through practical workshops and implementation guidance where additional assurance is needed. Transaction simulation exposes behaviour that would otherwise go unnoticed, and walk through a real example of how funds can be lost even when a transaction appears to execute correctly.

What is Transaction Simulation?

Transaction simulations aim to reduce this risk by providing a snapshot of the state before and after the transaction. The state can be thought of as a picture in time right before the transaction executes.

Traditional simulation methods like eth_call provide high-level validation but lack granular visibility into state changes, making hidden exploits difficult to detect. For example, what if a smart contract’s only purpose is to let you provide two values, add them together, and return them to you? Then surely this couldn’t be malicious, right?

Let’s say we had the contract with the following values: 1 and 1. Just because the smart contract returns to us 2, there is still room to exploit its functionality. What if this contract received approvals in USDC to pay for a small fee to add any number together? If the contract were upgradeable and compromised, it could keep the core logic and add malicious code between the addition of the two
numbers, returning a valid result and stealing your tokens.

Let's examine what a full transaction simulation reveals that a basic simulation test would miss:

Above shows that we put in the intended address of 0xC0deCafe and transferred 1,000 tokens. The event shows that we also did this. However, when we look at the storage for a last check, we can see that the tokens never showed up.

The storage slot above that, which went from 0 to 1,000 tokens, is owned by the malicious operator “0x5B38Da6a701c568545dCfcB03FcB875f56beddC4”. While basic checks ensured that the transfer function returned the proposal result. As showcased above, it does not provide the same level of security as a state diff.

For large-scale treasuries, traders, or anyone who needs strict security, the cost overhead is negligible compared to large-scale treasury or wallet drains.

While the following may show correct values:

1. Gas estimation may look normal.
2. Eth_call will show success, and even with traces, it will not provide enough scope to know if something malicious has occurred.
3. Events are emitted properly.

Even with these checks being correct, your funds are now gone permanently. Full transaction simulations provide the proper checks to execute transactions without a “what if” moment or hoping that everything goes well. Additionally, it provides a provable outcome compared to trusting the contract will return the correct value.

Recommended Simulation Tools

1. Tenderly
   1. Tenderly allows a UI based simulation to see the before and after changes of a transaction being executed.
   2. Tenderly supports virtual testnets, allowing chain forking, and precise state configuration to run any number of transactions and observe the results.
   3. Tenderly also supports API-based simulations that return state diffs in the response and can execute multiple transactions sequentially.
2. Foundry
   1. Foundry enables fast command-line simulations using cast call for quick contract queries. It also provides a testing suite that supports chain forking and custom smart contract testing environments.
3. Custom Tooling
   1. Integrating a monitoring solution that automatically simulates transactions before they’re signed and catches red flags before the signing process is completed.

Solution 2: Effective Monitoring

Continuous monitoring is the layer that validates assumptions in production and catches problems early. A layered approach should be used for monitoring. While Machine Learning alerts can be noisy and lead to false positives, they should be used in conjunction with stateful monitoring or additional checks on top before triggering an automated response, such as pausing or moving funds from a protocol. Machine learning excels at scanning bytecode for newly deployed, potentially malicious contracts that invariant check monitoring is not looking for.

The goal is to create a workflow that addresses each stage:

1. Detect — on-chain and off-chain monitors gather metrics and events.
   1. Alert fires with severity and a linked runbook.
   2. Automated response triggered if configured on top of monitor.
2. Triage — analysts and investigators confirm if the signal is real (such as simulate tx, compare oracle references, check governance queues).
   1. Mitigate — pause, move funds to avoid losses, or any other immediate action that needs to be taken.
   2. Communication — update partners quickly with an initial analysis of the implications of the alert on the protocol
3. Post Incident Review — assess if anything could have been done to catch this ahead of time or mitigate potential losses.
   1. Did security partners help?
   2. Was the war room efficient or chaotic?

In practice, effective monitoring changes outcomes. In one recent engagement, continuous monitoring identified malicious governance proposals early and automatically alerted the appropriate stakeholders, allowing the issue to be assessed and contained before execution. The underlying issue had the potential to result in losses measured in millions of USD, but early detection ensured security partners were aligned quickly and a coordinated response could be established with full context.

If you would like to discuss how effective simulations or on-chain monitoring can be designed, tuned, or operationalised within your environment, contact the zeroShadow vSOC team.